Design of an Integrated Circuit (IC) chip, including its architecture, is a very complex, expensive, and time-consuming task, making verification of that design before fabrication important. When designing increasingly complex processors or IC chips such as Application-Specific ICs (ASICs) and system-on-chips (SoC's), functional verification of the design has proven to be a major bottleneck in achieving time-to-market goals. Functional verification ensures functional conformance of an integrated circuit design to its architectural and microarchitectural specifications and determines whether a design is logically correct. The verification process involves developing and simulating tests that are used to determine whether design components (e.g., processor units, resources, functions, etc.) behave according to their functional specification. Verification of the design of a complex system such as an IC chip is an iterative process where the entire system (or at least all of its major features) is tested or simulated on a continuous basis for the duration of the design. As the design complexity increases, so does the state space and the number of functional states and finite state machines that need to be verified. In a typical microprocessor design environment, billions of simulation cycles are required to verify all features of the design.
IC chip designers typically build simulation models such as register-transfer-level (RTL) models to model and simulate the performance of design components. RTL models may be hardware models that have a direct correspondence to gate-level functions of IC chip hardware. Designers typically design RTL models in a hierarchical fashion where one design module encapsulates and instantiates submodules. The building-block approach of a hierarchical design makes it easier to build and test designs. As part of the hierarchical approach to designing RTL models, only a useful subset of the model's functional logic is preserved when the model is created. To reduce the size of the RTL model, logic that is redundant or unnecessary for functional simulation is eliminated in a process that is known as ‘flattening’ the RTL model. For example, redundant nets that are functionally or electrically equivalent may be eliminated from the RTL model and only the highest-level net be saved. Other control or data signals that are shared across multiple modules may be similarly removed from the RTL model. Similarly, logic made unnecessary by functions such as inversion or concatenation may also be removed from the RTL model. Reduction of the functional logic reduces the size of the RTL model and decreases the resources, such as the memory footprint, necessary to execute the model and perform simulations using the model.
Eliminating unnecessary logic from an RTL model does save on simulation resources, but it makes interfacing and debugging more difficult for human designers. Designers seeking to debug a particular net, for example, must determine if the net exists at the current level of hierarchy and if it does not, they must find out its designation in the model and then work with its actual designation. Such a process can be laborious and time-consuming. To assist with the process, alias files can be created during the model build process. When a model is recursively flattened during a build and equivalent nets are optimized out of the model, the location of the equivalent nets may be written to the alias file. The alias files thus provide a method to reconstruct optimized-out information from a model and to restore accessibility of that information by providing the necessary logic equation information that is not present in the model itself.
For large simulation models such as those for SoC designs, however, the massive size of alias files makes them difficult to work with. For these large simulation models that have many equivalent nets, the size of the alias file may reach hundreds of megabytes or higher, making them practically unmanageable for many purposes. A designer attempting to find information about particular signals stored in the alias file, for example, may have to use search tools such as ‘grep’ in UNIX to manually search the alias file, a cumbersome process. As alias files become larger and larger because of increased design complexity, the inconvenience of using them to find information also increases.
There is, therefore, a need for an effective and efficient system to access data from simulation models and files. There is an even greater need for such a system as the complexity of designs to be simulated continues to increase.